home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0081.01b < prev    next >
Text File  |  1995-03-01  |  11KB  |  271 lines
  1.  
  2.   | Document: FSC-0081 Part B
  3.   | Version:  001
  4.   | Date:     01 Mar 1995
  5.   |
  6.   | Mikael Ståldal, 2:201/337
  7.  
  8.            How the TYPE-3 packet format can coexist with TYPE-2
  9.                            in the same network.
  10.                     Mikael Ståldal, 2:201/337@FidoNet
  11.  
  12.  
  13. Introduction
  14. ============
  15. This document describes how to convert between the old TYPE-2 format and the
  16. new TYPE-3 format. The TYPE-2 format is documented in FTS-1 and FSC-39. This
  17. document only describes how to convert the packed messages, it should be
  18. obvious how to deal with the packet header if you read FSC-39 and the TYPE-3
  19. specification.
  20.  
  21. Read FSC-39, rev 4 for information on how to determine which format to use
  22. when sending packets to other nodes.
  23.  
  24. An FTN address in text format must, unless otherwise stated, be in the
  25. Zone:Net/Node[.Point] format, where .Point must be excluded if point is
  26. zero, included otherwise.
  27.  
  28. The field names in FTS-1 are used.
  29.  
  30. "kludge" means a line beginning with 01h in TYPE-2 messages.
  31.  
  32.  
  33. TYPE-2 => TYPE-3
  34. ================
  35.  
  36. General
  37. -------
  38. In Attribute, the Private, Crash, FileAttach, HoldForPickup, FileRequest,
  39. and FileUpdateReq bits is transferred to the MsgFlags field. The other bits
  40. are ignored. If a FLAGS kludge exists, it's checked for DIR, IMM, MCH, RRQ,
  41. CFM and PER which are used to set Direct, IMM, Machine, RRQ, CRQ and
  42. Permanent respectively. If IRR or ICR exists in a FLAGS kludge, they are used
  43. to set RRQ/IRR or CRQ/IRR.
  44.  
  45. DateTime is used to create the MsgDate field. If that fails, the MsgDate
  46. field is set to the current time.
  47.  
  48. If any FROMUSER3, TOUSER3 and/or SUBJECT3 kludges exist, they are used to
  49. create the FromUser, ToUser and Subject fields. Otherwise fromUserName,
  50. toUserName and subject are used.
  51.  
  52. If a TYPE3 kludge exists, it's used to create the MsgType and CharSet
  53. fields.
  54.  
  55. If any  CHRS, CHARSET or I51 kludges exist, they are used to create the
  56. CharSet field. I51 means CharSet=1. If any CHRS or CHARSET kludge indicates
  57. a character set not supported by TYPE-3, the message must be converted. If
  58. no such kludge exist, the CharSet field is set to 0. This is not performed
  59. if a TYPE3 kludge exists.
  60.  
  61. If a PTH kludge exist, it's used to create the Path field. Otherwise, the
  62. Path field is set to your address only.
  63.  
  64. If a MSGID kludge exists, the serial number is used to create the MsgID
  65. field. Otherwise it's set to null.
  66.  
  67. If an ORIG kludge exists, it's used to create the OrigAddr field, otherwise
  68. the address in the MSGID kludge is used. If the address doesn't contain
  69. organization, the name of your organization is added. If the ORIG kludge
  70. indicates that the message comes from another organization, set the Foreign
  71. flag. If non of these kludges exists the OrigAddr field is set to null.
  72.  
  73. If a REPLY kludge exists, the address is used to create the ReplyAddr field
  74. and the serial number is used to create the ReplyID field.
  75.  
  76. A split message (containing a SPLIT3 kludge) is rejoined.
  77.  
  78. If a TYPE3 kludge exists and contains UU, the text after it are UUdecoded
  79. and placed in the MsgData field.
  80.  
  81. Any quoted text in the FSC-32 format is converted to the TYPE-3 format.
  82.  
  83. Any binary extension fields (BIN3 kludges) are decoded.
  84.  
  85. Any FMPT, TOPT, INTL, BIN3, SPLIT3, CHARSET, CHRS, I51, ORIG, MSGID, REPLY,
  86. EID, PTH, PATH, RESCANNED and TYPE3 kludges are removed from the message
  87. text. Any other kludges are converted to extension lines, except kludges
  88. before any TYPE3 kludge which are converted to header extension fields.
  89.  
  90. destNode, destNet, together with any TOPT and INTL kludges are used to create
  91. the MsgDest field. If TOPT is missing, the Point field is set to 0. If INTL
  92. is missing, the Zone field is set to your zone.
  93.  
  94. If a DEST kludge with organization (called "domain" in FSC-58, rev 2)
  95. exists, the message is considered to be inter-organization and the DEST
  96. kludge is converted to a DEST header extension field. If a DEST kludge
  97. without organization exists, it's removed from the message text. In
  98. inter-organization messages, any ROUTE and ROUTD kludges are converted to
  99. header extension fields. However, a ROUTE kludge with the same address as
  100. MsgDest (check the organization too) must be removed.
  101.  
  102.  
  103. NetMail only
  104. ------------
  105. origNode, origNet, together with any FMPT and INTL kludges are used to create
  106. the MsgOrig field. If FMPT is missing, the Point field is set to 0. If INTL
  107. is missing, the Zone field is set to your zone.
  108.  
  109.  
  110. EchoMail only
  111. -------------
  112. The address in the Origin line is used to create the MsgOrig field. If no
  113. valid origin line exists, it is created as in NetMail.
  114.  
  115. The AREA line is used to create the Area field.
  116.  
  117. The AREA and SEEN-BY lines are removed from the message text.
  118.  
  119. If a RESCANNED kludge exists, the NoForward flag is set.
  120.  
  121.  
  122. TYPE-3 => TYPE-2
  123. ================
  124.  
  125. General
  126. -------
  127. In MsgFlags, the Pvt, Crash, File, Hold, FileReq and UpdReq bits is
  128. transferred to the Attribute field. If Direct, IMM, Machine and/or Permanent
  129. is set, a FLAGS kludge is created and set to DIR, IMM, MCH and/or PER
  130. respectively. If RRQ but not IRR is set, RRQ is added to the FLAGS kludge. If
  131. CRQ but not IRR is set, CFM is added to the FLAGS kludge. If RRQ and IRR is
  132. set, IRR is added to the FLAGS kludge. If CRQ and IRR is set, ICR is added
  133. to the FLAGS kludge. If IRR but not RRQ or CRQ is set, it's an error and
  134. should be ignored.
  135.  
  136. MsgDate is used to create the DateTime field. It must be set to the primary
  137. format specified in FTS-1.
  138.  
  139. FromUser, ToUser and Subject are transferred to the fromUserName, toUserName
  140. and subject fields. If they are too long, they are truncated. If any of them
  141. are too long, the whole field is put in a FROMUSER3, TOUSER3 and/or SUBJECT3
  142. kludge.
  143.  
  144. If CharSet is set to 1, a "CHRS: LATIN-1 2" kludge is created. If CharSet is
  145. set to 151, a "CHRS: IBMPC 2" kludge is created.
  146.  
  147. If the message originates in another organization (use the Foreign flag to
  148. check), the OrigAddr field is used to create an ORIG kludge.
  149.  
  150. MsgOrig is used to create the origNode and origNet fields. If Point is
  151. nonzero, a FMPT kludge must be created. An INTL kludge must always be
  152. created.
  153.  
  154. MsgDest is used to create the destNode and destNet fields. If Point is
  155. nonzero, a TOPT kludge must be created. An INTL kludge must always be
  156. created.
  157.  
  158. If MsgID is nonzero, OrigAddr and MsgID is used to create a MSGID kludge.
  159. The hexadecimal serial number must be in lowercase.
  160.  
  161. If ReplyAddr is nonzero, ReplyAddr and ReplyID is used to create a REPLY
  162. kludge. The hexadecimal serial number must be in lowercase.
  163.  
  164. Path is used to create a PTH kludge. This kludge must be the last one before
  165. any kludges coming from header extension fields.
  166.  
  167. A TYPE3 kludge is always created, it contains the value of MsgType in
  168. decimal followed by the value of CharSet in decimal. If the whole MsgData is
  169. UUencoded (as described later), the values must be followed by "UU". E.g.
  170. TYPE3 0 34
  171. TYPE3 1 123 UU
  172.  
  173. All other kludges kludges mentioned here must be before the TYPE3 kludge.
  174. Everything after the TYPE3 kludge is from MsgData, except Origin, SEEN-BY
  175. and PATH in EchoMail.
  176.  
  177. Any header extension fields are converted to kludges. They must be immediate
  178. before the TYPE3 kludge.
  179.  
  180. If MsgType is nonzero or CharSet indicates a 16- or 32-bit character set,
  181. the whole MsgData is UUencoded immediate after the TYPE3 kludge. The first
  182. line must be "begin 666 TYPE3" and the last line must be "end". It's
  183. possible to do this with all messages, but that will make it impossible to
  184. read them when in TYPE-2 format. Here is an example:
  185. begin 666 TYPE3
  186. MX.=E!/\#CG$13<92M*A7V][HV%;+\EHS?HTD=\?,QGP JT"R1D6 7:@2S=Z8
  187. M5?4(%E>RG;(D#=NBD(/U*QZ&5@&I#5Y',GH0WN1ORH!-M%DJ[1"H%#*M9R#]
  188. MUH[M13O:BHW<LM0I@RQJ"P*/"?:SPYOA9;I_4M16E7//<T,+)B]($"X)ANGY
  189. ' +]"
  190. end
  191.  
  192. Any extension lines are converted to kludges. They must be after the TYPE3
  193. kludge. This is not performed if the whole MsgData is UUencoded.
  194.  
  195. Any quoted text is converted to the FSC-32 format. This is not performed if
  196. the whole MsgData is UUencoded.
  197.  
  198. Any binary extension fields are UUencoded and put behind BIN3 kludges. The
  199. first line must be "begin 666 short" or "begin 666 long" depending on if
  200. it's a short or long binary extension field. The last line must be "end".
  201. Note that this must be done before any splitting and it's possible to split
  202. a message in the middle of an binary extension field. This is not performed
  203. if the whole MsgData is UUencoded. Here is an example (all lines must have
  204. the kludge char 01h first):
  205. BIN3 begin 666 short
  206. BIN3 MX.=E!/\#CG$13<92M*A7V][HV%;+\EHS?HTD=\?,QGP JT"R1D6 7:@2S=Z8
  207. BIN3 M5?4(%E>RG;(D#=NBD(/U*QZ&5@&I#5Y',GH0WN1ORH!-M%DJ[1"H%#*M9R#]
  208. BIN3 MUH[M13O:BHW<LM0I@RQJ"P*/"?:SPYOA9;I_4M16E7//<T,+)B]($"X)ANGY
  209. BIN3 ' +]"
  210. BIN3 end
  211.  
  212. If the message is larger than 64 KB, it's split in several smaller
  213. messages. All kludges mentioned in this document except MSGID and REPLY must
  214. be in all parts. MSGID and REPLY must only be in the first part. Kludges not
  215. mentioned in this document (those coming from extension lines) are treated
  216. as normal text. All parts have a SPLIT3 kludge which contains the MSGID
  217. followed by a space, the part's number, a slash ("/", 2Fh) and the number of
  218. parts. The SPLIT3 kludge must be the first kludge except INTL, FMPT and
  219. TOPT. In all parts, a space, a left parenthesis, the part's number, a slash
  220. the number of parts and a right parenthesis is added to the subject field; the
  221. last chars of it are overwritten if there isn't enough room. If no MSGID
  222. exists because MsgID was zero, the message comes from TYPE-2 and should not
  223. be larger than 64 KB; if it is, it should not be split. Note: you may use
  224. a smaller maxlength than 64 KB (such as 16 KB). All parts must be in the
  225. right order immediately after each other in the same packet or the rejoining
  226. may not work.
  227. Example:
  228. Subject: Hello boys!
  229. FMPT 5
  230. MSGID: 1:234/567.5 12345678
  231. REPLY: 2:345/678 23456789
  232. CHRS: IBMPC 2
  233.           |
  234.           V
  235. Subject: Hello boys! (1/3)
  236. FMPT 5
  237. SPLIT3 1:234/567.5 12345678 1/3
  238. MSGID: 1:234/567.5 12345678
  239. REPLY: 2:345/678 23456789
  240. CHRS: IBMPC 2
  241.           +
  242. Subject: Hello boys! (2/3)
  243. FMPT 5
  244. SPLIT3 1:234/567.5 12345678 2/3
  245. CHRS: IBMPC 2
  246.           +
  247. Subject: Hello boys! (3/3)
  248. FMPT 5
  249. SPLIT3 1:234/567.5 12345678 3/3
  250. CHRS: IBMPC 2
  251.  
  252.  
  253. EchoMail only
  254. -------------
  255. Area is used to create a AREA line. If Area contains multiple AreaTags, one
  256. message for each area are created.
  257.  
  258. If the NoForward flag is set, a RESCANNED kludge is created.
  259.  
  260. If no origin line exist an origin line with only address are created and the
  261. address is set to MsgOrig. No search for Origin is performed if the whole
  262. MsgData is UUencoded.
  263. Example:
  264.  * Origin: (1:234/567)
  265.  
  266. Create SEEN-BY line(s) with all addresses in Path after the last zone change
  267. that isn't points. Including those with "!" after.
  268.  
  269. Create PATH line(s) with all addresses in Path after the last zone change
  270. that isn't points. Except those with "!" after.
  271.